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REMARKS/ARGUMENTS 

Claims 1 -5 and 7-20 of the present application have been rejected by the Examiner. The 
Examiner has recognized allowable subject matter in claim 6. Claims 1-5 and 7-20 have been 
rejected under 35 U.S.C. § 102(b) as being unpatentable over United States Patent No. 5,403,21 8 
to Svedberg ("Svedberg")* 

With regard to the rejection of claim], applicants respectfully disagree with the position 
of the Examiner. Svedberg teaches a model-based coordination system for coordinating primary 
and secondary alarms in order to ascertain whether the alarms are earned by a single fault or 
multiple faults and to determine the location of the fault. Svedberg is a method of root cause 
failure determination in an electrical system. The flow diagram of FIG. 1 1 is instructive. Once an 
error (fault) is detected the only question is whether the current managed object (MO) is causing 
the fault. If it is then a fault identifier is created and information on the fault is sent to 
functionally dependent managed objects. If the current MO is not at fault then the system 
determines whether the fault is caused by one or more server MOs. The types of faults that are 
being detected are faults in the physical layer as indicated by FIG, 10 which depicts an external 
cable wherein a failure of the cable would lead to independent primary fault notifications from 
each port unless the cable is modeled as an MO. Thus, the system of Svedberg enables faults to 
be properly grouped and reported. 

The present invention is distinguished from Svedberg in a number of ways. A first 
primary difference is that the method and system of the present invention is directed to a 
prioritization and handling of service alarms. Service alarms are a type of alarm that was not 
contemplated by Svedberg. Svedberg does not teach or suggest the use of a service model 
dependency graph in order to handle service alarms or alerts. A telecommunications service is 
comprised of a plurality of service components as depicted in FIGS. 1-9 and 13 of the present 
application. A service may be dependent upon physical layer components as well as components 
in other layers of the network. The dependency in a service model dependency graph (unlike in 
Svedberg) is not strictly a function of physical interconnectivity. Additionally, a key element of 
the present invention is the use of a component status indicator (CSI) for a component based on a 
set of pre-defined rules and the CSI of downstream components and alert handle information. At 
each component a CSI generated based on the impact a downstream alert and CSI has on a 
specific service. This enables the system to determine whether an alert is actually service 
impacting and therefore important enough to propagate further or whether propagation of the alert 
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should be halted at a specific component. This neither taught nor suggested by Svedberg. 
Svedberg is aimed only at localization of the alarm in order to determine the location of a fault for 
purposes of correcting the fault and for alerting connected MOs of the fault. There is no teaching 
or suggestion of a set of rules that generates a component status indicator for a component based 
on the CSI of a downstream component. 

The Examiner cites column 7, lines 49-68 of Svedberg as teaching the use of a service 
model dependency graph of the present invention. Applicants submit that Svedberg teaches only 
the use of a physical layer (electrical system) dependency model that is used to propagate alarms 
from one electrically connected physical component to another. This does not equate to the 
service dependency graph of the present invention. There is no use of a component status 
indicator generated based on alerts and CSFs from other components as in the present invention, 
Svedberg simply propagates an alarm, determines if the alarm is local to an MO and them 
propagates an alarm handle to connected MOs that identifies the location of the alarm. In this 
manner an upstream MO that is not working knows that its failure is due to a different MO and 
can pass this information on. 

With respect to claim 2 there is no teaching or suggestion in Svedberg of having a 
component status indicator that is associated with a path an alert handle has taken through the 
service model dependency graph. First, there is no teaching of a service model dependency 
graph. Second, the Examiner relies broadly on FIGS. 4-7 as showing this feature of the present 
invention but there is no text that describes such a path. 

Claim 3 is neither taught nor suggested by Svedberg. The Examiner cites column 8, lines 
16-31 as teaching the use of a handle that includes information about the time of the alert, the 
type of the alert and the duration of the alert. Applicants respectfully disagree. The cited passage 
of Svedberg discusses the detection of faults in the electrical system and the time for detection of 
the fault and propagation of a fault identification message by the MO. This is not the same as 
placing information about the alert's time, type and duration in a handle as in the present 
invention. 

Claim 4 is neither taught nor suggested by Svedberg. The Examiner only generally cites 
FIGS. 4-7 of Svedberg as teaching the step of generating a service impact index at the top level of 
the service model dependency graph wherein the service impact index is an indicator of the 
impact of downstream alerts on the quality of service. This is neither taught nor suggested by 
Svedberg which does not teach the use of a service model dependency graph or the generation of 
a service impact index. Svedberg does not discuss the concept of quality of service. Svedberg is 

Page 6 of 8 



PAGE 9/11 * RCVD AT 2/1712005 1:52:45 PM [Eastern Standard Time] 1 SVR: USPTO-EFXRF-6/34 * DHIS:2738300 1 CSID:17323363Q04 1 DURATION (mm-ss):03-20 



FEB-17-0G 13.30 FROM . TELCORD I A TECHNOLOGIES IDt 17323363004 PAGE 10/11 

Appl. No. 10/779,432 APP1516 

Amdt. Dated February 17. 2006 

Reply 10 Office Action of October 21 , 2005 

not about quality of service but rather only about the localization of electrical physical layer 
faults. Quality of service can be affected by physical layer faults, software faults, usage and 
many other factors. 

Applicants respectfully disagree that claim 5 is either taught or suggested by Svedberg. 
Claim 5 adds the step of summing the service impact indexes to generate a total impact index. 
This is neither taught nor suggested by FIG. 9 or the accompanying text of Svedberg. Fig. 9 
depicts a "pool" MO and its relationship with pool members. FIG. 10 is an example of such a 
4i pool" MO which enables a failure to be modeled as a single failure rather than several 
independent failures. This is not the same as the summing of the service impact index to create a 
total impact index. The total impact index is used by the network operator to determine whether 
there is a serious degradation of quality of service based on a plurality of service impact indexes. 
The service impact indexes themselves being generated based in a plurality of component status 
indicators. It does not refer to pooling a set of faults to be modeled as a single fault. 

Claims 7 and 8 indicate how different the systems of Svedberg and the present invention 
are. In claim 7, a root cause analysis is performed if the system determines if there is a service 
impacting component status indicator. Svedberg is only about determination of the root cause 
and identification of the location of an alarm. There is no teaching or suggestion in Svedberg that 
this root cause analysis is performed only if there is a service impacting component status 
indicator. There is no discussion in Svedberg of retrieving the path that service-affecting handles 
have taken through the service dependency graph. There is no service dependency graph in 
Svedberg and there is no mention of a path through such. In Svedberg, a fault is identified at an 
MO and an alert with the location of the fault is propagated to other MOs that are electrically 
dependent upon it. 

Claims 9 and 10 are neither taught nor suggested by Svedberg. FIGS. 4-7 do not teach or 
suggest the prioritization of alerts based on the service impact index or the total impact index. 
There is no discussion of either type of index or even of a service dependency graph in Svedberg. 

Claim 1 1 is neither taught nor suggested by Svedberg because there is no teaching of the 
generation of a component status indicator based on alerts and component status indicators of 
other components related in a service dependency graph. Claims 12 and 13 are novel for the 
same reason. 

Claim 14 is neither taught nor suggested by Svedberg because Svedberg does not teach 
distinguishing between service affecting alerts and others, inherently or otherwise. 
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Claims 15-20 are distinguished from Svedberg to the same reasons set forth above. The 
system claimed by claims 15-20 is neither taught nor suggested by Svedberg for the following 
reasons. There is no discussion in Svedberg of a system for handling alerts wherein a 
telecommunications networie is modeled as a service model dependency graph. Nor is there any 
teaching of a rule engine which utilizes both the component status indicator of one or more 
downstream components and handles generated in response to alerts to generate a component 
status indicator for each component. Furthermore, there is no teaching or suggestion of such a 
rule engine residing at each component as in claim 16 or in the network operations center as in 
claim 17. Furthermore there is no teaching of a means for generating a service impact index or a 
total impact index at the network operation center as claimed in claims 19 and 20. Such means 
are entirely missing from Svedberg. 

Applicants thank the Examiner for recognizing the novelty and non-obviousness of claim 
6. Applicants respectfully suggest that claims 1-5 and 7-20 are also allowable over Svedberg. 
Applicants hereby request reconsideration of claims 1-5 and 7-20 in view of the above remarks 
and allowsince thereof is respectfully requested. 

A one-month extension of time is hereby respectfully requested. 



Respectfully submitted. 



Telcordia Technologies, Inc. 




William A. Sch&rfeman 
Reg. No. 38,047 
Tel.: (732) 699-3050 
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